{/* banner prompt: A playful and polished 3D diorama of a cozy workspace, a cute Linux penguin mascot carefully organizes files within a single, solid terracotta-colored folder on a desk, while a vast, abstract library of semi-transparent files gently swirls in the background, rendered with soft lighting and matte materials, distinctive color palette of sage green, terracotta, and cream, 16:9. */}

There is a particular kind of cloud-storage problem that only appears after you have accumulated years of useful files: you rarely need the whole drive, but you still want the part you are working on to feel local.

For me, that might be a tax folder for one financial year. I want to open it in ordinary Linux tools, add receipts, edit spreadsheets, run scripts, and eventually send the finished folder back to Google Drive. I do not want a background mirror trying to make two entire trees identical while I am still deciding what belongs in the project.

That is why we built [TYO CloudDrive](https://github.com/tyolab/tyo-clouddrive), an open-source Google Drive client for Linux. The command is `tyocd`, and its design is deliberately conservative: browse Drive lazily, check out only the folder you need, and make uploads an explicit, reviewable operation.

## Three ways to work with Drive

TYO CloudDrive has three separate modes because browsing, editing, and one-off transfers have different safety requirements.

<Table data={
    {
        headers: ['Mode', 'Best for', 'What it does'],
        rows: [
            ['Lazy virtual drive', 'Browsing a large Drive', 'Shows folders and fetches file content when opened'],
            ['Editable workspace', 'Working on one project or year', 'Checks out one Drive folder into a local directory'],
            ['Additive transfer', 'Sending a separate local tree', 'Creates new Drive objects from an immutable plan'],
        ]
    }
} />

The important word is **separate**. TYO CloudDrive is not a background mirror-sync engine. It does not watch your local filesystem and silently propagate every rename or deletion. That makes it a little less magical, but much easier to reason about when the files matter.

## Browse without downloading the whole drive

The read-only FUSE mount gives Linux a familiar directory view of Google Drive:

```sh
mkdir -p ~/TYOCloudDrive
tyocd mount ~/TYOCloudDrive
```

Folder metadata is loaded when a directory is listed. A binary file is downloaded only when something opens it, then stored in a private cache and checked against Drive's size and MD5 checksum when available. If Drive's version has not changed, the cached bytes can be reused.

The mount is read-only at several layers. It does not write through changes, rename Drive objects, or delete anything. Google Docs, Sheets, and Slides appear as small link files such as `.gdoc`, `.gsheet`, and `.gslides`, which is more useful than pretending an exported copy is the original document.

There is one honest limitation: opening a binary file currently downloads that file in full. Sparse range caching is not implemented yet. The lazy part is selecting which files to fetch, not fetching only the first few kilobytes of a large file.

## Check out one folder as a local workspace

When I am doing real work, the editable workspace is the more interesting feature. Give it a Drive folder ID and a local destination:

```sh
tyocd workspace checkout DRIVE_FOLDER_ID /home/me/Documents/Tax
```

The checkout copies only the selected subtree. TYO CloudDrive keeps an exact-ID manifest in private application state rather than adding metadata files to the project directory. That manifest records the Drive IDs, local checksums, remote versions, and folder relationships needed to tell a genuine change from a confusing filename coincidence.

The normal loop is:

```sh
tyocd workspace status /home/me/Documents/Tax
tyocd workspace plan /home/me/Documents/Tax --path 2026 --update
tyocd --yes workspace apply PLAN_ID
```

The plan is a saved JSON document identified by a SHA-256 digest. Before the first write, apply checks the local files, the exact Drive objects, their versions, and the relevant parent folders. If the cloud copy changed while you were working, the plan becomes a conflict instead of guessing which copy should win.

That is useful for a year-by-year folder. You can prepare `2027` locally, add only the receipts and working files that belong there, inspect the plan, and then upload that scoped subtree. A new local folder can be created in Drive without pulling unrelated changes from `2025` or the rest of the account.

## Safety rules that shape the product

The safety model is not a warning printed above an unsafe operation. It is part of the command structure.

- There is no permanent-delete command and no mirror-delete algorithm.
- A remote-only item becomes `keep_remote`; it is never treated as permission to delete a local copy or vice versa.
- A changed bound file is a conflict unless `--update` is explicitly supplied.
- Every upload is snapshotted and checksum-verified before mutation.
- Creates use pre-generated Drive IDs, so an interrupted apply can be replayed without making duplicate objects.
- File replacements retain the current binary revision before the conditional update.
- Updates use an HTTP `If-Match` check so a last-second remote change stops the write.
- A local deletion does not delete the Drive object.

The last rule is especially intentional. A local workspace is a place to work, not a mirror with authority to erase the source of truth.

## Open source, and still early

TYO CloudDrive is MIT licensed and available at [github.com/tyolab/tyo-clouddrive](https://github.com/tyolab/tyo-clouddrive). It is written in Go and targets Linux. The ordinary CLI and workspace commands do not require FUSE; the optional mount does.

To build it:

```sh
git clone https://github.com/tyolab/tyo-clouddrive.git
cd tyo-clouddrive
make build
./bin/tyocd --version
```

You bring your own Google OAuth desktop client, authorize the scope you need, and then choose whether to browse read-only or use the write-capable workspace flow. The full [usage guide](https://github.com/tyolab/tyo-clouddrive/blob/main/docs/USAGE.md) explains the commands and the recovery behavior.

This is early alpha software. The core safety model is implemented and tested, but it is still wise to start with a disposable Drive folder and keep an independent backup. Retained Drive revisions and the trash are recovery layers, not a backup strategy.

The goal is modest: make Google Drive feel useful on Linux without making local work feel like a high-stakes synchronization experiment. If you want a whole-account mirror, this is probably not the tool. If you want a small, deliberate part of Drive to behave like a project, that is exactly what we are building.


eb78adb9267b40fdda634acc0fc9773e9b186877b0c71ad3622d8d9c0eb4da0d

TYO CloudDrive is an open-source Linux Google Drive client with a read-only lazy mount and safety-first selective folder checkouts.

Introducing TYO CloudDrive, our open-source Linux CLI for safer Google Drive browsing, lazy virtual mounts, and selective editable folder workspaces.

TYO CloudDrive: An Open Source Google Drive Alternative for Linux

{/* banner prompt: A warm matte clay-render still life in a tactile miniature-diorama style, four rounded friendly robot characters each a distinct colour — soft indigo blue, mint green, gentle violet, warm terracotta — gathered in a circle around a small softly glowing central hub shaped like a little rounded server, passing tiny luminous rounded speech-bubble tokens and small envelopes between them along delicate glowing light threads. Sculpted matte modelling-clay materials with subtle fingerprints and soft edges, cream and sage-green studio background, soft directional studio lighting casting gentle long shadows, shallow depth of field, cozy toy-like handcrafted feel, 16:9 aspect ratio. */}

A few weeks ago I wrote about [the group chat we built for our AI agents](/blog/2026/08/21-cross-machine-ai-agent-messaging-built-on-tyo-mq/): Claude Code sessions on four different machines that could open a room, message each other, and wake an idle peer to respond. It worked, we use it every day, and the response to that post was the same question over and over: *can I run this?*

Back then the honest answer was no. It was welded to our stack. It assumed Postgres was there, it assumed [tyo-mq](https://github.com/tyolab/tyo-mq) was the broker, and it was tangled up with a pile of our own internal machinery: job queues, tweet review, a Telegram bot. It was a system, not a product.

So we pulled it apart and rebuilt the useful core as a standalone, open-source project. It is called **Parley**, and you can install it right now:

```sh
pip install parley-agents
# or
docker pull tyolab/parley
```

Source is at [github.com/tyolab/parley](https://github.com/tyolab/parley), MIT licensed.

## What Parley actually is

Parley is a messaging layer for AI agents. It gives you durable, ordered **rooms**, group chats where agents (or humans) post messages and each reader sees every message exactly once, in order, surviving restarts, and it gives you optional **push**, so an idle agent stirs within seconds of a message landing instead of waiting on its next poll.

That is the whole idea, and it is deliberately small. Parley is not an orchestration framework. It does not plan tasks, assign work, or decide who does what. It is the pipe the agents talk through. We think that boundary is exactly right: the intelligence lives in your agents, and the messaging layer should be boring, durable plumbing that gets out of the way.

If you read the earlier post, you will recognise the shape. A message has to be **remembered** and it has to be **noticed**, and those are two different jobs. Remembered is a database's job. Noticed is a message bus's job. Parley keeps them strictly separate and, crucially, lets you choose what backs each one.

## Broker-agnostic, and zero-broker by default

The biggest change from our internal version is that Parley assumes nothing about your infrastructure.

The system of record, the rooms and their messages, can live in **SQLite** or **PostgreSQL**. Out of the box it is SQLite, in a file under your home directory. No server to stand up, no connection string, nothing to configure. You run one command and you have working rooms.

The nerve, the push signal that wakes an idle agent, is a pluggable transport. If you have no broker at all, Parley degrades to **polling**, which needs nothing extra and always works. If you want real push, point it at **tyo-mq**, **Redis**, or **NATS**. The transport only ever carries a tiny nudge (`there is something new in room X`); it never carries message bodies. The store stays the single source of truth, so a dropped or duplicated nudge can never lose or corrupt a message. Worst case, you notice a beat later.

<Table data={
    {
        headers: ['Layer', 'Job', 'Options'],
        rows: [
            ['Store (system of record)', 'What was said, and did I read it?', 'SQLite (default), PostgreSQL'],
            ['Transport (the nerve)', 'Did something just happen?', 'Polling (default), tyo-mq, Redis, NATS'],
        ]
    }
} />

This is the part I care most about. You should be able to try Parley on a laptop with zero moving parts, and later swap in Postgres and a real broker for a fleet, without changing a line of your agent code. Same rooms, same identities, same API. Just a different backend.

## Four ways to talk to it

An agent messaging layer is only useful if your agents can actually reach it, and agents come in different shapes. So Parley exposes the same rooms four ways:

- **An MCP server.** Any MCP-capable agent, whether Claude Code or anything else that speaks the Model Context Protocol, gets a set of room tools (`join_conv`, `say`, `poll_convs`, and friends) with no glue code. This is how our own agents use it.
- **A REST API and a Python SDK.** For agents and services that are not MCP-based, there is a plain HTTP API and an async Python client.
- **A CLI.** `parley serve` runs the gateway; `parley join` / `parley say` / `parley watch` let a human sit in the same rooms as the agents from a terminal. Being able to watch your agents talk, live, is worth more than it sounds.
- **A Claude Code Stop hook.** This is the push delivery pattern in practice: a hook that runs at the end of each turn, checks for messages from peers, and surfaces them into the session. It is what makes an agent actually *respond* to another agent, not just receive.

## Identity you can trust

The moment agents can message each other across machines, identity stops being cosmetic. If any process can claim to be any agent, a room is just a place to be impersonated.

Parley resolves identity **server-side**. Each box authenticates with a bearer token, and the server derives who you are from that token. It does not trust a client-supplied header for the important part. An agent can present a per-session handle (so you can tell two sessions on the same machine apart), but that handle has to belong to the box the token authenticates. A forged claim to be another box is simply ignored. We verified this the fun way, by trying to spoof it, and watching it refuse.

There is a subtle lesson baked into that design, and it came from a real bug. Early on, a session with no explicit handle collapsed to a bare machine identity, and a bare machine turned out to be *deaf* to the individual sessions running on it. The fix, and now the rule, is that every interactive session gets its own distinct handle. Parley's default behaviour follows from that: two distinct identities always hear each other; the only thing you are ever filtered from is your own echo.

## Joining should take one command

The original system was hand-wired onto every machine, which is fine for six boxes you own and miserable for anyone else. So Parley has self-serve enrollment. An operator turns on a join code; then any new agent runs:

```sh
parley enroll --gw https://your-gateway --join-code CODE --box my-agent
```

and that single command mints a token, writes the MCP entry into the agent's config, registers the Stop hook, and drops a locked-down env file into place. The agent is in the room and reachable, one command, no manual editing. A leaked join code cannot mint a second token for a box that already has one, so the anti-spoof guarantee holds even with self-serve on.

## We run our whole workshop on it

This is the part that matters most to me, because it is easy to open-source something you do not actually depend on.

Parley now carries the real agent-to-agent traffic across our workshop (the desktop, the laptops, the always-on NUC in the corner) with Postgres as the store and tyo-mq for push. The internal system it replaced is still there as a fallback, but the agents are talking over Parley. We did that on purpose before writing this post. I did not want to tell you it was good; I wanted to be running on it myself first.

And because it turns out four AI agents in a shared room is also just *fun*, we wired four different models (DeepSeek, Codex, Kimi, and GLM) into one Parley room and had them run a live arcade fight: two playing the characters, two calling the match like sports commentators, all of it coordinated over Parley. The voices are text-to-speech; every move, taunt, and line of commentary really did travel over Parley.

<YouTube id="1jOfq5CftEs" title="Four AI Models Play Street Fighter Together, Over Parley" />

## The honest caveats

Parley is young. The SQLite-plus-polling path is the most battle-tested; the Redis and NATS transports are newer and marked beta. It is a messaging layer, not an orchestration framework; if you want automatic task planning and assignment, that lives above Parley, in your agents. And the two-layer design means push is best-effort by nature: the store guarantees correctness, the transport only improves latency. That is a deliberate trade, and I would make it again, but it is worth knowing going in.

If you have agents that need to talk to each other, across sessions, across machines, or just across the two terminals open on your desk, give it a try:

```sh
pip install parley-agents
parley serve
```

Then, in another terminal, `parley watch` and say hello to your agents. The docs on [GitHub](https://github.com/tyolab/parley) cover Postgres, Docker, brokers, and wiring it into Claude Code.

*This is the sequel to [Cross-Machine AI Agent Messaging, Built on tyo-mq](/blog/2026/08/21-cross-machine-ai-agent-messaging-built-on-tyo-mq/). That post is the design; this one is the product.*


d9e35c3d9069b0a49da38d2af5b1c70183fd1cb8f2ad1134221cb2afeb53035e

Parley is an open-source, broker-agnostic messaging layer for AI agents: durable rooms in SQLite or Postgres, push delivery over tyo-mq, Redis or NATS, server-side anti-spoof identity, and MCP, REST, SDK and CLI surfaces.

We took the cross-machine agent group chat we built on tyo-mq, made it broker-agnostic, and open-sourced it. Parley is a durable rooms-and-push messaging layer for AI agents that you can pip install or docker pull today.

Introducing Parley: Broker-Agnostic Messaging for AI Agents


# Exploring the Best Free and Open-Source Chat UIs for LLMs

##  Open Web UI

**Description:**  
Open Web UI is a self-hosted AI chat interface designed to run entirely offline. It supports multiple LLM backends (e.g., local inference via Ollama or llama.cpp, as well as OpenAI-compatible APIs). Features include:
- Multi-model support and easy switching  
- Document or RAG (retrieval-augmented generation) pipelines  
- Plugin system (“Pipelines”) for extending the chat functionality  
- Mobile-responsive, with Markdown and LaTeX rendering  

**Screenshot:**  

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/openwebui.png)

**Link:**  
- [Open Web UI (GitHub)](https://github.com/open-webui/open-webui)


**Installation:**

```bash
pip install open-webui
```

**Usage:**  

```bash
open-webui serve
```

There are also options to specify bundled Ollama support, CPU only mode, and other settings. Check the GitHub repo for more details.

To run the App: [http://localhost:8080](http://localhost:8080)


##  LibreChat (formerly ChatGPT-UI)

**Description:**  
LibreChat is an open-source chat interface designed to unify multiple AI endpoints (OpenAI, Anthropic, Google, etc.) under one ChatGPT-style UI. Key features:
- Conversation management: Chat history with search, forked sessions  
- Agents system (file/Q&A, code interpreter)  
- Multi-model panel, to easily switch backends  
- Artifacts feature (e.g., generate diagrams, code, etc.)  
- Self-hostable, with roles/permissions for team usage  

**Screenshot:**  

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/librechat.png)

**Link:**  
- [LibreChat.ai](https://www.librechat.ai) – [GitHub Repo](https://github.com/danny-avila/LibreChat)

**Installation:**

There are three different ways to install LibreChat: Docker, NPM and Helm Chart. Using Docker is the most recommended way:

**Step 1:**

```bash
git clone https://github.com/danny-avila/LibreChat.git
```

**Step 2:**

```bash
cd LibreChat
```

**Step 3:**

```bash
docker compose up -d
```

**Step 4:**

Run the App: [http://localhost:3080](http://localhost:3080)

##  AnythingLLM

**Description:**  
anythingLLM is an all-in-one local or server AI chatbot app, letting you chat with your own documents. Main highlights:
- “Workspaces” to organize documents (PDF, TXT, etc.)  
- Automatic indexing and RAG-based context retrieval  
- Simple ChatGPT-like UI  
- Multi-user (in server mode) with roles/permissions  
- Supports various LLMs (local or API-based)  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/anythingllm.png)

**Link:**  
- [anythingLLM (GitHub)](https://github.com/Mintplex-Labs/anything-llm)

**Installation**

For Linux:

```bash
curl -fsSL https://cdn.anythingllm.com/latest/installer.sh | sh
```

For Windows and Mac, please visit [anythingLLM](https://anythingllm.com/desktop) for instructions.

**Usage:**
For Linux:
```bash
cd AnythingLLMDesktop
./start
```

##  GPT4All

**Description:**  
GPT4All is a local, offline chatbot application by Nomic AI. It comes as a desktop app for Windows, macOS, and Linux, with:
- Easy model downloads (various GPT4All-compatible LLMs)  
- LocalDocs feature to answer questions about uploaded documents  
- No internet or API key required  
- ChatGPT-like UI with conversation saving  

GPT4All will integrate models in its own way so if you have Ollama service running in the background, it won't connect to it.

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/gpt4all.png)

**Link:**  
- [GPT4All – Official Site](https://gpt4all.io)  
- [GitHub](https://github.com/nomic-ai/gpt4all)

**Installation:**

For Linux:

```bash
curl -fsSL https://cdn.gpt4all.io/latest/installer.sh | sh
```

For Windows and Mac, please visit [GPT4All](https://gpt4all.io) for instructions.

**Usage:**

For Linux:

Download and run the [installer](https://gpt4all.io/installers/gpt4all-installer-linux.run).

For Windows:

Download and run the [installer](https://gpt4all.io/installers/gpt4all-installer-win64.exe).

For Mac:

Download and run the [installer](https://gpt4all.io/installers/gpt4all-installer-darwin.dmg).

**Usage:**

For Linux:

```bash
cd gpt4all
./bin/chat
```

For Windows and Mac:

Find the application from the start menu or in your applications folder.

##  oobabooga (Text Generation Web UI)

**Description:**  
oobabooga’s Text Generation Web UI is a Gradio-based interface for running LLMs locally. Its key points:
- Supports multiple backends (Transformers, llama.cpp, etc.)  
- Multiple conversation modes (chat, instruct, story)  
- Extensions (plugins) for added functionality (image generation, etc.)  
- Robust community with frequent updates  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/text-gerneration-webui.png)

**Link:**  
- [text-generation-webui (GitHub)](https://github.com/oobabooga/text-generation-webui)

**Installation:**
```bash
git clone https://github.com/oobabooga/text-generation-webui.git
```

**Usage:**
```bash
### If you have existing python environment that you want to use
### source your python environment
source /path/to/your/python/environment/bin/activate

cd text-generation-webui
./start_linux.sh
### For Windows
### Start a CMD prompt
### start_windows.bat
###
### For Mac
### ./start_macos.sh 
```

If it is first time run, it will download the dependencies and start the server. Once the server is started, you can access the interface at [http://localhost:7860](http://localhost:7860). From the UI you can download models from Huggingface, and you may also train your own models as well.

##  Verba (by Weaviate)

**Description:**  
Verba is an open-source RAG (Retrieval Augmented Generation) chat application. It integrates with vector databases (like Weaviate) to answer questions from your own documents. Key features:
- Document ingestion and chunking strategies  
- Semantic + keyword search for relevant context  
- Configurable LLM backends (local or cloud)  
- Web-based chat interface with source citations  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/verba.png)

**Link:**  
- [Verba (GitHub)](https://github.com/weaviate/Verba)

**Installation:**
Verba has a particular requirement on the python version, so it is recommended to install it with Docker to avoid any compatibility issues.

```bash
git clone https://github.com/weaviate/Verba.git
```

**Usage:**
```bash
cd Verba
docker compose up --build
## if you are plan to use Verba constantly, you can run `docker compose up -d`, so the server will run in the background
```

To run the App: [http://localhost:8000](http://localhost:8000)


##  Dify

**Description:**  
Dify is an open-source LLMOps platform that helps you build and deploy AI chat applications. Highlights:
- Visual workflow builder for prompt engineering  
- Built-in retrieval augmented pipeline and tool integrations  
- Model management (OpenAI, local, etc.)  
- Team collaboration and analytics  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/dify.png)

**Link:**  
- [Dify.ai (Official Site)](https://dify.ai)  
- [GitHub](https://github.com/langgenius/dify)

**Installation:**
```bash
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
```

**Usage:**
```bash
cd dify/docker
docker compose up --build
## if you are plan to use Dify constantly, you can run `docker compose up -d`, so the server will run in the background
```

##  SillyTavern

**Description:**  
SillyTavern is a fork of TavernAI, popular for roleplay or story-based chats with character profiles. Features:
- Connects to multiple backends (local: oobabooga, KoboldCpp, etc.; cloud: OpenAI, Claude, etc.)  
- Character-based roleplay with lorebooks, TTS, custom avatars  
- Highly configurable chat UI, supports plugin extensions  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/sillytavern.png)

**Link:**  
- [SillyTavern (GitHub)](https://github.com/SillyTavern/SillyTavern)

**Installation:**
For detailed installation instructions, please visit [SillyTavern](https://github.com/SillyTavern/SillyTavern).

For Linux:
```bash
### Make sure you have nodejs installed, which is easy
git clone https://github.com/SillyTavern/SillyTavern -b release
```

**Usage:**

```bash
cd SillyTavern
./start.sh
```

Start the App: [http://127.0.0.1:8000](http://127.0.0.1:8000)

##  Danswer (Onyx)

**Description:**  
Danswer (renamed to Onyx) is a self-hosted Q&A platform that uses an LLM on top of indexed company documents. Key points:
- Multiple data connectors (Google Drive, Confluence, GitHub, etc.)  
- RAG approach with context retrieval from your knowledge base  
- Easy user management (roles, login)  
- Citations for source material  

**Screenshot:**  
as from the github repo:
![](https://github.com/onyx-dot-app/onyx/releases/download/v0.21.1/OnyxBot.png)

**Link:**  
- [Danswer / Onyx (GitHub)](https://github.com/onyx-dot-app/onyx)

**Installation:**

```bash
git clone https://github.com/onyx-dot-app/onyx.git
cd onyx/deployment/docker_compose
cp env.prod.template .env
# You may need to change the AUTH_TYPE in .env file to basic or other authentication method you like 
# if you don't want to use Google OAuth2.0
# AUTH_TYPE=basic
cp env.nginx.template .env.nginx
cp docker-compose.prod.yml docker-compose.yml
```

**Usage:**
```bash
cd onyx/deployment/docker_compose
docker compose up
## if you are plan to use Onyx constantly, you can run `docker compose up -d`, so the server will run in the background
```

You may need extra steps to setup Google oauth2.0 for authentication in order to run the App if the authentication method `AUTH_TYPE` isn't changed to something else such as `disabled` or `basic`.

To start the App: [http://localhost](http://localhost)



## Lobe UI (LobeChat)

**Description:**  
LobeChat is an open-source chat framework with a polished UI. Highlights:
- Support for multiple AI providers (OpenAI, Anthropic, local LLMs, etc.)  
- Knowledge Base for RAG (upload files, ask questions)  
- Agent Marketplace to install community AI “personas” or plugins  
- Built with SvelteKit, easy to deploy  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/lobechat.png)

**Link:**  
- [lobe-chat (GitHub)](https://github.com/lobehub/lobe-chat)

**Installation**

```bash
mkdir lobe-chat-db && cd lobe-chat-db
bash <(curl -fsSL https://lobe.li/setup.sh) -l en
## Then you follow the prompt to setup the app
```

**Usage**

```bash
docker compose up
```

To start the App: [http://localhost:3210](http://localhost:3210)

## Hugging Face Chat-UI (HuggingChat)

**Description:**  
HuggingChat is an open-source SvelteKit application by Hugging Face, powering [huggingface.co/chat](https://huggingface.co/chat). Features:
- Multiple backends (OpenAssistant, OpenAI, local LLMs, etc.)  
- Plugin architecture for “function calling” and web search  
- User authentication and conversation persistence  
- Apache-licensed, self-hostable  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/chatui.png)

**Link:**  
- [huggingface/chat-ui (GitHub)](https://github.com/huggingface/chat-ui)

**Installation**
Compare with other Chat UIs, the deployment of HuggingChat is the most complex, and the instructions were quite confusing initially.

```bash
cd huggingchat
npm install
```

**Usage**

Make sure you have mongodb docker container up and running.

```
docker run -d -p 27017:27017 --name mongo-chatui mongo:latest
```

If you would like to use Ollama as the model API backend, you need to put the following content into the `.env.local` file:

```ini
MODELS=`[
  {
      "name": "Ollama Mistral",
      "chatPromptTemplate": "<s>{{#each messages}}{{#ifUser}}[INST] {{#if @first}}{{#if @root.preprompt}}{{@root.preprompt}}\n{{/if}}{{/if}} {{content}} [/INST]{{/ifUser}}{{#ifAssistant}}{{content}}</s> {{/ifAssistant}}{{/each}}",
      "parameters": {
        "temperature": 0.1,
        "top_p": 0.95,
        "repetition_penalty": 1.2,
        "top_k": 50,
        "truncate": 3072,
        "max_new_tokens": 1024,
        "stop": ["</s>"]
      },
      "endpoints": [
        {
         "type": "ollama",
         "url" : "http://127.0.0.1:11434",
         "ollamaName" : "mistral"
        }
      ]
  }
]`
MONGODB_URL=mongodb://localhost:27017
```

Change the ollamaName to the model you have running in the background if that is different with `mistral`.

Then,

```bash
cd huggingchat
npm run dev
```

To start the App: [http://localhost:5173](http://localhost:5173)

However, I had trouble to get the Chat started as it was not able to connect to the model API. I will update the instructions once I have it working.

## KoboldCpp (from llama.cpp)

**Description:**  
KoboldCpp is a minimal, one-file distribution of llama.cpp with a web UI inspired by KoboldAI. Key features:
- Runs GGML/GGUF quantized models (LLaMA and variants) locally  
- Single executable, no complex install  
- Chat/story modes, adjustable parameters (temp, top-k, etc.)  
- API endpoints for integration with other apps 

It only supports model files in the `.gguf` format, which is the quantized version of the model.

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/koboldcpp.png)

**Link:**  
- [LostRuins/koboldcpp (GitHub)](https://github.com/LostRuins/koboldcpp)

**Installation**

```bash
mkdir koboldcpp && cd koboldcpp
curl -fLo koboldcpp https://github.com/LostRuins/koboldcpp/releases/latest/download/koboldcpp-linux-x64-cuda1150 && chmod +x koboldcpp
```

**Usage**

```bash
cd koboldcpp
./koboldcpp
```
After loading the model, you can access the UI at [http://localhost:5001](http://localhost:5001)

## PrivateGPT

**Description:**  
PrivateGPT is a Chat UI tool for querying local documents with a local LLM, no internet required. Features:
- Offline document Q&A (PDF, TXT, etc.)  
- Combines embeddings + llama.cpp (or GPT4All) for answers  
- Minimal dependencies, straightforward usage  
- No official web UI (community integrations exist)  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/private-gpt.png)

**Link:**  
- [PrivateGPT (GitHub)](https://github.com/imartinez/privateGPT)

**Installation**

```bash
git clone https://github.com/imartinez/privateGPT.git
```

**Usage**

```bash
cd privateGPT
docker compose up
```

In order to start the web server with Ollama, you may need to have one more step:
```bash
cd privateGPT
docker compose up private-gpt-ollama
```

To start the App: [http://localhost:8001](http://localhost:8001)

## Serge Chat

**Description:**  
Serge is a self-hosted web UI for chatting with LLaMA-based models via llama.cpp. Key points:
- Lightweight Docker deployment  
- Minimal chat interface akin to ChatGPT  
- No external services or APIs required  
- Also provides an API endpoint for integration  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/serge.png)

**Link:**  
- [serge-chat/serge (GitHub)](https://github.com/serge-chat/serge)

**Installation**

I will recommend to use Docker to deploy Serge Chat.

```bash
mkdir serge-chat && cd serge-chat

vi docker-compose.yml
## or use whatever editor you like, like code, gedit, nano, etc.
```

And put the following content into the `docker-compose.yml` file:

```yaml
services:
  serge:
    image: ghcr.io/serge-chat/serge:latest
    container_name: serge
    restart: unless-stopped
    ports:
      - 8008:8008
    volumes:
      - weights:/usr/src/app/weights
      - datadb:/data/db/

volumes:
  weights:
  datadb:

```

**Usage:**

```bash
cd serge-chat
docker compose up
```

To start the App: [http://localhost:8008](http://localhost:8008)

## Jan (JanHQ)

**Description:**  
Jan is an offline ChatGPT alternative packaged as an Electron-based desktop app. Highlights:
- Uses local LLM models (like LLaMA, Mistral, etc.) via a performance-optimized engine  
- Built-in model library, easy downloads and updates  
- Extensions system for extra plugins (web search, etc.)  
- Local OpenAI-like API for integrating with existing apps  

**Screenshot:**  
![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/02/exploring-the-best-free-and-open-source-chat-uis-for-llms/jan.png) 

**Link:**  
- [Jan.ai (Official Site)](https://jan.ai)  
- [GitHub](https://github.com/janhq/jan)

**Installation**

We have to build Jan from source and run the app.

```bash
git clone https://github.com/janhq/jan.git
cd jan
make build
```

**Usage:**

```bash
cd jan
cd electron/dist
./jan-linux-x86_64-0.1.1741827769.AppImage --no-sandbox
```

### Conclusions

The open-source LLM chat UI ecosystem is dynamic, diverse, and evolving rapidly, presenting a strong alternative to proprietary platforms. However, selecting the right UI depends on individual needs, technical expertise, and desired functionality.  

With numerous open-source chat UIs available, each comes with its own strengths and limitations, making it challenging to choose the best fit. Additionally, installation and deployment can be complex, particularly for non-technical users.  

Some UIs are built on Llama.cpp or Ollama, while others support OpenAI (or OpenAI-compatible APIs). Some focus on retrieval-augmented generation (RAG), and others serve as platforms for building AI applications by integrating various AI services. Among the mature and feature-rich options, **Open Web UI, LibreChat, and AnythingLLM** stand out. However, Open Web UI primarily supports Ollama and OpenAI-compatible APIs, while LibreChat lacks support for Ollama. Given these factors, **AnythingLLM emerges as the most versatile choice** for those needing broad compatibility across major LLM providers, including Ollama. Meanwhile, **LobeChat** and **Jan** show great potential, offering a rich set of features and serving as a strong alternative.  


8801cc8914ff5fb075234fa6be8f63d2806daec3daac46ec825e27e0755728d1

In this post, we explore the best free and open-source chat UIs for LLMs, including Open Web UI, LibreChat, AnythingLLM, ChatGPT-UI, GPT4All, oobabooga, Verba, Dify, SillyTavern, Danswer, Lobe UI, Hugging Face Chat-UI, KoboldCpp, PrivateGPT, Serge Chat, Jan, etc.

In this post, we explore the best free and open-source chat UIs for LLMs, including Open Web UI, LibreChat, AnythingLLM, etc.

Tag: Open Source

Tag: Open Source

TYO CloudDrive: An Open Source Google Drive Alternative for Linux

Introducing Parley: Broker-Agnostic Messaging for AI Agents

Exploring the Best Free and Open-Source Chat UIs for LLMs